https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=311627137#content/view/311627137

背景故事

身為一個優秀有責任感的工程師，在程式裡面關鍵處埋下各種 log 訊息是一定要做的事情。Kafka 身為一個優秀的分散式系統，使用 slf4j 來提供足夠的訊息讓維護者可以看 log 知天下事。

不過作為一個熱門的系統，Kafka 被很多使用者引用來開發各式各樣的應用，slf4j 這套框架自然也被引用在使用者的程式裡面。換言之，Kafka 如果要更換 slf4j 的版本勢必會影響到許多使用者，尤其 slf4j 在相容性上有特別要求 API 和 provider 的版本要一致 … 看到這裡，是不是突然不太清楚 API 和 provider 是什麼？沒問題，馬上來說明說明：

• slf4j API 顧名思義就是定義了一系列的介面，讓使用者可以很方便的抽換底層的實作
• slf4j provider 自然就是各種基於不同 log 系統來實作 slf4j API 的東西

一般來說，slf4j 的使用者在自己的專案內會「明確」定義 slf4j 的版本，以避免踩到相容性的坑，但是你知我知工程師這麼忙有時候就是會忘了保持好習慣，因此 Kafka 身為一個很在意相容性的系統，自然需要多為使用者著想來好好看一下該怎麼解決這個問題！

解決辦法

第一種方式最簡單，那就是每次要升級的時候就昭告天下，同時我們也降低升級slf4j的頻率，例如只有在明確 CVE 的時候升級，如此來降低撞到相容性問題的機率

第二種方式比較極端，我們可以將所有 provider 包含在 kafka 裡面，如此使用者不需要宣告自己的 provider 而是安心的用 kafka 所提供的版本，同時使用者也可以利用 slf4j 2版新增的功能 「slf4j.provider」來選擇偏好的 provider。

第三種方式是我們從此定調保持版本一致屬於使用者的責任，Kafka 只負責維護 slf4j API 和 slf4j-reload4j 的一致性。

後續

截稿至今，社群依然在討論要選擇哪一種方式最為適合，所以強大的讀者如果有任何的想法，都歡迎到社群上回饋你的想法喔

https://lists.apache.org/thread/f753ghgvcw860sc8znvhkyvg8scnkm0n

ps. 上方連結是 Apache 中每個開源專案都會有的頻道，統稱爲 dev channel，在該頻道我們會討論各種需要公告給所有開發者知道的資訊，以 kafka 爲例，當我們有重大技術決策時，就會提出 Kafka Improvement Proposal (KIP)，並且公告在 dev channel 以充分收集所有人的寶貴意見。因此不管你有沒有參與過 kafka 開發都可以針對 dev channel 裡面的各種討論發表意見，正面負面都可以，開源領域保持開闊的心胸接納並歡迎大家的想法

廣告
歡迎訂閱全臺最鬆散的開源社群源來適你，上面不定期會有各種開源的廢文。也歡迎參加全臺最鬆散的開源討論頻道，上面有一群網友一起在刷開源技術